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(57) Abstract: The invention 
relates to a method of generating a 
performance model from a functional 
model of a system comprising 
a plurality of co-operating and 
distributed hardware and software 
entities in order to provide a service 
to at least one user. The inventive 
method comprises the following 
steps consisting in: dividing the 
requests that are representative of the 
system into a finite number of groups 
and, for each group of requests, 
identifying the corresponding 
execution stream; formalising the 
execution streams using a notation 
which can be used to demonstrate 
(i) the causal relations between the 
different system software entities 
involved in the execution stream 
and (ii) the data that characterise the 
resource consumption of the system; 
producing an intermediate model; 
and automating the transformation 
of the intermediate model produced 
into a performance model. 
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(57) Abrege : U invention concerne un proc£d6 de generation d'un modele de performance a partir d'un modele fonctionnel d'un 
sy steme comportant une plurality d'entitSs materiel les et logiciels reparties cooperant pour fournir un service a au moins un utilisa- 
teur. Le proc6d6 selon l'invention comporte les Stapes suivantes :- RSpartir les requetes representatives du systeme en un nombre fini 
de groupes et identifier, pour chaque groupe de requetes, le flot d'execution correspondant, - Formaliser les flots d J executions a l'aide 
d'une notation permettant de mettre en evidence, d'une part, les relations causales entre les diff^rentes entit^s logicielles du systeme 
impliquees dans les flots d'execution, et d 1 autre part, les informations caract£risant la consommation des ressources du systeme,- 
Elaborer un modele interm^diaire, - Automatiser la transformation du modele intermeciiaire 61abor6 en un modele de performance. 
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PROCEDE DE GENERATION D'UN MODELE DE PERFORMANCE A 
PARTI R D'UN MODELE FONCTIONNEL 

DESCRIPTION 

5 Domaine technique 

L' invention se situe dans le domaine de 1' etude 
des performances par simulation d'un systdme, tel que 
par exemple un syst^me de telecommunication comportant 
une plurality de composants materiels et logiciels 
10 r^partis et qui cooperent pour fournir un service a un 
ou plusieurs utilisateurs . 

L' invention concerne plus specif iquement un 
procede de generation d'un modele de performance a 
partir d'un moddle fonctionnel d'un tel systdme . 

15 

Etat de la technique anterieure 

Lors de la realisation puis du deploiement d'un 
systdme, il faut s' assurer qu' il possede les capacites 
f onctionnelles attendues, mais aussi qu'il tiendra la 

20 charge dans les conditions d' exploitation. Si les 
performances chutent, il peut meme arriver que le 
■ systeme ne remplisse plus les services pr^vus . Une 
etude de performance a pour premier object if de prevoir 
les phenomenes d' ecroulement du systdme afin d'eviter 

25 tout dysf onctionnement . 

L' etude de performance permet de connaitre 
d'une fagon precise la repartition des ressources du 
systdme et d' identifier ainsi les eventuels goulots 
d' etranglement . Un second objectif est d'ordre 

30 economique. Il s'agit de determiner les configurations 
optimales des ressources, afin de maximiser leur 
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efficacit£ et ainsi d'eviter 1' achat d' gquipements 

supplementaires . Le dimensionnement des ressources 
. consiste k determiner les parametres quant itat if s 

necessaires pour la qualite de service d6sir<Se tels que 
5 par exemple la taille des tampons, le nombre de 

serveurs, la repartition des entit6s de traitement sur 

les differentes machines, etc. 

Une 6tude de performance s'effectue soit sur un 

rnodele, soit sur le systSme reel par des mesures. 
10 Lorsque c'est sur un module, on peut gen^ralement 

observer deux types de comport ement du systeme etudie, 

le comportement transitoire et le comportement 

stationnaire. Le premier porte sur des periodes courtes 

et le second sur des periodes longues . Les - approches 
15 les plus sollicitees sont notamment les techniques 

math6matiqu.es, la simulation discrete, et 1 ' analyse 

basee sur des graphes. 

Les notations pour exprimer les modules sont 

souvent des types suivants : 
20 - systemes a files d'attente, 

- r^seaux de Petri temporises, 

- automates temporises , 

- modeles hierarchiques ou descriptions textuelles dans 
des langages specialises. 

25 L' Evaluation des performances depend de la 

technique utilis<§e qui doit §tre choisie en tenant 
compte des caracteristiques de 1 ' application 
consideree. Les techniques de resolution sont classEes 
en trois categories principales z 

3 0 - la mEthode analytique, 

- les tests rEels, et 
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- la simulation. 

La methode analytique fait appel le plus 
souvent a la theorie des systemes a files d'attente, ou 
aux reseaux de Petri stochastiques . 

Les systemes a files d'attente restent l'un des 
plus puissants formalismes mathematiques permettant 
d' analyser quantitativement une tres grande variete de 
systemes. Par exemple, un systeme informatique peut 
§tre considere, de manidre trds abstraite, comme un 
ensemble de ressources materielles et logicielles 
(serveurs) utilisees par des ttches ou des programmes 
(clients) . Les ressources 6tant en nombre limits, les 
programmes vont entrer en concurrence pour l'acces a 
ces ressources, et l'on resout cette concurrence par 
des files d'attente. 

Le formalisme des reseaux de Petri repose sur 
une representation graphique qui permet de bien 
comprendre le comportement du systeme. Ce formalisme 
convient notamment aux systemes dont le comportement 
est fortement caracterise par les aspects de 
concurrence, de synchronisation, de communication et de 
cooperation. Le systeme peut etre analyse 
qualitativement (absence d' inter-blocage, surete de 
fonctionnement , etc.). 

Un handicap majeur du rSseau de Petri reside 
dans 1' explosion du nombre d'etats a examiner lorsque 
la complexity du systeme augment e . 

L'approche analytique, enfin, consiste 

generalement a exprimer le comportement du systeme sous 
forme d'un modele mathematique exact aboutissant a des 
formules closes. Le comportement du systeme est alors 
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reduit a. un ensemble de variables liees entre elles par 
des equations. L'atout principal de cette approche 
analytique reside dans le fait qu'elle ne necessite pas 
d'outil de support sophistique lors des phases de 
modelisation et de resolution du probleme, ce qui 
convient particulierement aux phases amont de la 
conception d'une application. Avec cette approche, il 
suffit d'appliquer la formule pour determiner les 
quant ites recherchees et surtout pour connaxtre 
1' influence relative des differents parametres . Cette 
approche, qui requiert couramment de fortes hypotheses 
(independance des evenements, conservativite des 
serveurs, etc.), s'avere praticable pour des systemes a 
1 ' architecture f onctionnelle relativement simple tels 
15 que par exemple 1' etude des systemes de commutation des 
reseaux de transport. En outre, la methode analytique 
s'avere bien adaptee a 1' etude des «pires cas» de 
comportement du systeme, en faisant des approximations 
simplif icatrices et pessimistes. 
20 Cependant, les systemes logiciels se pretent 

beaucoup moins bien aux methodes analytiques, car ils 
presentent beaucoup de variantes de comportement. En 
effet, le comportement du systeme d' exploitation depend 
fortement de 1 ' architecture de la machine, sur laquelle 
25 on ne dispose souvent que de tres peu d' informations . 
Aussi, les interactions entre les differents processus 
peuvent etre tres complexes et difficiles a 
caracteriser par des lois probabilistes . 

Dans les systemes repartis, des complications 
suppl£mentaires apparaissent du fait de la cooperation 
entre des systemes heterogenes ou seule une vue 
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partielle de 1'etat du systeme est disponible au niveau 
de chaque composant . Dans le cas des services de 
telecommunication, il est egalement difficile de 
caracteriser le comportement des clients qui g^nerent 
5 le trafic des requetes. 

A I 7 oppose de la methode analytique, 1'approche 
par tests reels consiste, moyennant une infrastructure 
d' observation (sondes), & faire des mesures directement 
sur le systdme reel. L' observation se fait g<§n6ralement 

10 soit au niveau logiciel, soit au niveau du systdme 
exploitation, soit aux deux niveaux en meme temps. 
Cette approche a pour avantage l'obtention de resultats 
reels, notamment pour la capacity de traitement limite 
du systeme (montee en charge) . 

15 La mesure des performances sur un systeme r£el 

n^cessite de disposer d'une implantation complete du 
systeme a tester (materiels et logiciels) , par 
consequent 1' etude ne peut §tre menee qu'a posteriori, 
et peut impliquer des achats de materiels couteux. La 

20 realisation d'une sonde pour inspecter le systdme est 
une tache difficile car 1 ' instrumentation ne doit pas 
perturber de maniere significative ce que l'on mesure. 
En particulier, La repartition des machines n^cessite 
une synchronisation d'horloges satisf aisante . De plus, 

25 toute modification logicielle bu matSrielle entraine un 
surcout de mise en oeuvre en termes d' interop6rabilit£ 
et de portability, de reconfiguration, et de r£glages. 
En outre, les programmes de tests doivent §tre 
d£velopp6s et eux-memes testes et sont fortement li£s 

3Q au code r6el de 1 ' application ce qui est d'autant plus 
contraignant que les processus de developpement et de 
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mise en exploitation d'une application sont courts. II 
faut done souvent developper en paralldle 1' application 
et les programmes de tests, ce qui induit de fortes 
contraintes de synchronisation au niveau. de 
5 1' organisation du d^veloppement . Enfin, les tests reels 
souffrent d'une limitation qui provient du fait que 
seules des configurations simples peuvent etre 
consid6rees. Par exemple, la capacity de traitement est 
6valuee en testant le comportement du systeme lorsque 

10 des demandes de service arrivent simultan^ment . Par 
contre, pour connaitre 1' evolution du temps de r^ponse 
(temps maximum, temps moyen, repartition,..)/ de 
1' occupation des tampons et du taux de pertes, il faut 
gen^rer un tres grand nombre de requetes pour que les 

15 resultats statistiques des tests soient representatif s . 
D' autre part, il faut aussi g€nerer des flux d'arriv^e 
de ces requites selon des scenarii representatif s du 
comportement des utilisateurs . Ces flux sont 
caracterises notamment par le taux d'arriv6e moyen et 

2 0 le rythme (d6terministe, en rafale, al^atoire sur une 

duree, exponentiel . . . ) . Ces contraintes imposent de 

disposer de plusieurs machines clientes, car le nombre 
~ de processus act if s par CPU est souvent limits a 

quelques centaines. II faut ggalement pouvoir les 
25 synchroniser pour que le comportement des utilisateurs 

genere soit proche de la r6alitS, ce qui est tres 

difficile a mettre en oeuvre . 

L'approche par simulation semble de loin la 

plus utilisee . pour 1' evaluation des performances de 

3 0 toutes sortes de syst^mes et consiste Sl modeliser le 

comportement du systeme, le plus souvent k l'aide d'un 
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systeme a files d'attente ou d'un reseau de Petri, puis 
a experimenter le modele en faisant varier un ensemble 
de parametres correspondant aux diff^rentes 
configurations du systeme. Par exemple, pour . des 
5 systemes logiciels, les parametres peuvent §tre la 
vitesse de calcul des processeurs, le debit de 
transmission des rSseaux, la politique d' ordonnancement 
des processus, le nombre et la topologie des machines, 
- le taux et le rythme d'arrivee des requetes, etc.. La 

10 simulation est plus aisee k apprehender, et plus 
puissante que la methode analytique. En effet, la 
formulation du modele a simuler ne s'exprime pas sous 
forme d' equations mais de programmes, ce qui permet de 
construire un moddle aussi proche que possible du 

15 systdme reel 6tudi6 . Elle est beaucoup moins coflteuse 
en materiel et en logiciel que 1' approche par tests car 
elle exploite un modele (une abstraction, une 
representation virtuelle) au lieu d'un systeme reel. 
Cette approche fournit un outil puissant pour la 

2 0 prediction des performances depuis la conception du 

systdme a 6tudier jusqu'a sa realisation. 

Des simulateurs logiciels genSralistes sont 
apparus depuis 1980 et on peut citer par exemple QNAP 
[http : /www . hyperf ormix . com] , SIMSCRIPT 
25 [http: /www. caci.com/index__main.shtml] , OPNET 
[http : /www . opnet . com] , et SES/Workench 

[http: /www. hyperf ormix. com] . 

Contrairement aux campagnes de tests, le temps 
d' executions d'une simulation n'est pas lie aux temps 

3 0 reels des traitements de 1 ' application. Ainsi, 

1' approche par simulation permet de r^aliser un plus 
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grand nombre de sc^narii en faisant simplement varier 
les parametres du modele. La mise au point d'un modele 
permet souvent d'enoncer des conjectures sur le syst&me 
consider^ et de pressentir plus facilement certains 
5 616ments de r^ponses au probleme de la performance. Les 
simulations permettront de confirmer ou d' inf irmer ces 
conjectures. D'autres elements, tels que la 
distribution du temps de reponse de bout en bout ou du 
taux de perte, sont le plus souvent tres difficiles £ 
10 quantifier et seule la simulation permet de les mettre 
en evidence. 

L'approche par simulation se deroule en quatre 

phases : 

• . 1' elaboration du modele de comportement du 

15 systeme : elle commence par la selection des entites du 
systeme (un composant logiciel, un processus, etc.) 
qu'il est judicieux de modeliser, par rapport aux 
objectifs precis de l'6tude de performance. 
L' elaboration se poursuit par la description du 

2 0 fonctionnement de ces entit^s, ainsi que de leurs 
interactions. Les entites sont choisies en fonction de 
la finesse desiree des r^sultats de la simulation, mais 
^ aussi en fonction des donnees initiales qui peuvent 

etre procur6es. Les parametres sont des 

25 caracfceristiques signif icatives des elements du systeme 
(par exemple, temps de traitement unitaire d'une entite 
sur un processeur, nombre de serveurs, etc.), qui sont 
susceptibles d' inf luencer les resultats de simulation, 
Les modules sont representes ggn^ralement soit par des 

30 systemes a files d'attente (QNAP, SIMSCRIPT, 
SES/Workbench) , soit par des automates (OPNET) , soit 
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par des reseaux de Petri . 

• 1' acquisition des donnees quantitatives pour 
alimenter les simulations : pour des systemes 
logiciels, ces donnSes correspondent notamment aux 

5 temps de traitement des programmes sur les processeurs 
et aux dSlais de transmission si des acheminements a 
travers des reseaux ont lieu. Elles sont mesurees par 
des tests unitaires. Un test unitaire de traitement, ou 
de dSlai de transmission, correspond respect ivement au 
10 temps d'utilisation du processeur (unite centrale) , ou 
du reseau quand la ressource est entierement dedi€e au 
processeur. 

• les simulations et la collects des resultats 
statistiques : on observe le comportement du systeme en 

15 executant le modele a 1 ' aide d' un simulateur et en 
faisant varier ses param^tres ; on analyse les 
resultats de chaque simulation et on en deduit des 
resultats de performance pour les configurations 
choisies . 

2 0 • validation du modele de simulation : la confiance que 

l'on peut accorder aux resultats de simulations 
nScessite une validation du module. Elle consiste a 
realiser quelques tests reels representatif s 
soigneusement choisis et k confronter ces resultats 
25 reels avec ceux obtenus par simulation. 

De maniere genSrale, l'approche par simulation 
constitue un bon compromis entre cout de mise en oeuvre 
et valeur des resultats. En faisant varier divers 
parametres, elle permet d'6tudier le comportement d'un 

3 0 systdme ou d'une application sous une grande vari<§t§ de 

configurations. Ceci sans avoir toute 1' infrastructure 
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cible du systdme (materiel et logiciel) et, pour les 
applications, sans en faire le developpement complet. 
Par ailleurs, elle convient parfaitement lorsque 1'on 
veut comparer des differentes technologies ou produits, 
5 ainsi que pour dimensionner et optimiser le systdme en 
cours d' Elaboration. 

Les principales difficultes de 1'approche par 
simulation resident dans la capture du comportement du 
systeme a etudier, l'obtention des mesures 
10 quantitatives unitaires et la connaissance statistique 
du comportement des clients du systeme. En effet, tout 
modele de simulation est une approximation du systeme 
r g e l, et la fidelite du modele a la rEalite depend 
fortement de la finesse des connaissances disponibles 
15 sur le f onctionnement du systSme. Or les systemes 
logiciels sont souvent des produits qui se presentent 
sous forme de « boites noires » , c'est-a-dire de 
programmes exEcutables dont on ne dispose pas des 
specifications. L' introduction d'outils de traces pour 
2 0 comprendre les mecanismes et les comportement s internes 
et pour disposer des mesures unitaires sur tous les 
elements qui composent le systeme dans la modelisation 
<cr est une tache indispensable et delicate. En outre, la 
connaissance du comportement des utilisateurs joue 
25 egalement un role primordial pour alimenter les 
simulations, loi d'arrivEe des requites, repartition 
des scenarii utilisateur, etc. En effet, ces Elements 
ont une incidence non nEgligeable sur la performance du 
systdme, notamment en ce qui concerne les temps de 
30 reponse. Cette connaissance ne peut etre fournie que 
par des mesures sur un systeme rEel. Or, en gEnEral 
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tres peu de statistiques sont disponibles a ce sujet. 
De . plus, pour de nouvelles applications, une 
mod^lisation anticipee des profils des utilisateurs est 
necessaire. 

5 Le passage d'un modele base sur les aspects 

f onctionnels d'un systeme a un modele de performance a 
fait l'objet de plusieurs travaux cites a titre 
d'exemples ci-aprds. 

Timed SDL (TSDL) [F. Bause and P. Buchholz, 

10 Qualitative and Quantitative Analysis of Timed SDL 
Specifications'', in N. Gerner, H. G. Hegering, J. 
Savolvod, (Eds.) Springer- Verlag, 1993] impl^mente une 
forme de systSmes de transitions temporises, construits 
a partir d'une specification SDL dans laquelle & chaque 

15 transition, est attach^e une duree exponent i el le . 11 
n'inclut pas de notions de ressources ou de charge. A 
partir d'une representation intermediaire sous la forme 
d' automate, l'outil effectue des analyses qualitatives 
et quantitatives en utilisant des algorithmes de type 

2 0 Markovien. 

DL-net [H. M. Kabutz, "Analytical performance 
evaluation of concurrent communicating systems using 
°^ SDL and stochastic Petri nets", Doctoral Thesis, 
department of Computer science, University of Cape 
25 Town, Republic Of south Africa, 1997] transforme un 
module SDL appauvri (soumis & de fortes restrictions 
sur les types de donnees) en ion module QPN (Queuing 
Petri Nets), c ' est-S.-dire un riseau de Petri muni de 
files d'attente. C'est seulement £ ce second niveau que 

3 0 sont introduites les informations stochastiques de 

dur<§e. Un outil convertit ce moddle en une chaine de 
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Markov qui est ensuite resolue. La semantique de la 
description SDL originale peut etre differente de celle 
de SDLnet, mais des solutions p.ragmatiques acceptables 
ont ete proposees, du point de vue des auteurs de cette 
5 approche . 

SPECS (SDL Performance Evaluation of Concurrent 
Systems) [Butow M. , Mestem M. , Schapiro C, Kritzinger 
P. S., «Performance Modeling from Formal Specifications 
», FORTE- PST y' 96, Kaiserslautern, Germany, October 
10 1996] permet de modeliser les ressources (les machines) 
par des blocs SDL et les taches s' executant sur une 
machine par des processus a 1 ' interieur d'un meme bloc. 
Les processus dans des blocs differents s'executent de 
maniere concurrents, alors que les processus du meme 
15 bloc s'executent dans un mode multittche. Des delais de 
canaux et des caracteristiques de fiabilite peuvent 
dtre ajoutes. Le modele s' execute sur une machine 
virtuelle qui est derivee du modele SDL. 

SPEET (SDL Performance Evaluation Tool) [M. 
20 Steppler, M. Lott, "SPEET - SDL Performance Evaluation 
Tool", in A. Cavalli, A. Sarma (Ed.), SDL' 97 - Time for 
Testing, Proceeding of the 8 th SDL Forum, Elsevier, 
1997.] a pour objectif principal 1' analyse de 
performances de systemes specifies en SDL s' executant 
25 dans un environnement temps-reel. Les systemes peuvent 
§tre simules ou executes sur des emulateurs de 
materiels existants (Intel®, Motorola® et Siemens®) . 
lis sont stimules par des generateurs de trafics et 
sont interconnectes par des liens de transmission 
correspondant a des canaux physiques. Les utilisateurs 
peuvent definir facilement des sondes a 1' interieur de 
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la description formelle et introduire des indications 
de charge . 

Les approches de [E. Heck, "Performance 
Evaluation of Formally Specified Systems — the 
5 integration of SDL with HIT" , doctoral Thesis, 
University of Dortmund, Krehl Verlag, 1996.] et de 
[Martins J., «A system Engineering Methodology 
Integrating performance evaluation and Formal 
Specification », PhD Thesis, l'Ecole polytechnique 

10 federale de Lausanne, Avril 1996] introduisent un cadre 
conceptuel (HIT) visant une synthese des techniques de 
description formelle et devaluation de performance oti. 
les propri<§t£s issues de ces deux mondes seraient 
pr6serv£es. Un outil transforme un moddle SDL en un 

15 module HIT poss^dant une structure hierarchique 
pertinente pour 1' etude de performances* Une traduction 
(manuelle pour 1' instant) a egalement &t6 proposee vers 
un module OPNET, ce qui permet de b£nef icier de 
simulateurs performants. 

20 QUEST [M . Diefenbruch, "Fonctional and 

Quantitative Verification of Time-and resource Extended 
SDL Systems with Model -checking u , in : K Irmscher, 
c ^ (Ed.), Proceeding of Messung, Modellierung und 

Bewertung van Rechen-und Kommunikationssyste,nen, 

25 Freiberg, Germany,. VDE-Verlag, 1997] est basS sur un 
langage, QSDL (Queueing SDL), qui est une extension du 
langage SDL. En ajoutant des annotations indiquant les 
machines qui fournissent des services, des disciplines 
de service, la gestion des files d'attente dans le 

30 module SDL, le modele QSDL permet d'evaluer par 
simulation la performance du syst^me correspondant 
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specif ie en SDL. II permet egalement de valider et de 
verifier un systeme SDL temporise par model checking. 

DO-IT Toolbox [A. Mitschele-Thiel and B. 
MUlier-Clostermann, «Performance Engineering of SDIJMSC 
5 systems*, Journal on Computer Networks and ISDN 
Systems, Elsevier, 1998] effectue 1' evaluation de 
performance de systemes specifics en MSC et en SDL. Son 
originalite est de partir des MSC qui sont disponibles 
tres t6t dans le cycle de vie, en y ajoutant des 

10 annotations de charge et precisant les ressources 
disponibles pour des executions specif iques du systeme. 
II fournit une technique simple devaluation de 
performance pour 1' analyse de goulots d' Strang lement et 
1' optimisation d' implementations, a partir d'hypotheses 

15 de temps de service d^terministes . 

EaSy-Sim [C. Schaffer and R. Raschhofer, A. 
Simma, xx EaSy-Sim A Tool Environement for the design of 
Comnplex, Real-Time systems", Proceeding International 
Conference on computer Aided Systemns technologies, 

20 Innsbruck, Springer-Verlag, 1995] est un couplage entre 
l'environnement GEODE pour SDL et le simulateur 
SES/Workbench . L'environnement SDL est utilise pour la 

c verification et la validation f onctionnelle , alors que 
SES/Workbench modelise la partie non f onctionnelle pour 

25 evaluer la performance. Le couplage est implements par 
des echanges de messages entre le code executable de 
1' application obtenu par GEODE et le simulateur 
SES/Workbench. Cet outil peut s'appliquer a une 
specification MSC dans lequel des exigences de temps de 

30 reponse sont ajout#es pour des systemes temps reel [C. 
Schaffer "MSC/RT: A Real-Time extension to Message 
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Sequence Charts (MSC) , Internal Report TR 140-96, 
Institut fur Systemwissenschaf ten, . Johannes kepler 
universitat Linz, 1996] . 

EDT (Estelle Developement Tool) [M. Hendaz, « 
5 Annotation Dynamique pour Evaluation de Performance des 
systemes specifies en Estelle », these doctorat a 
l'Universite Paris 6, 1996.] est un ensemble d' outils 
bases sur le langage Estelle. Le traducteur transforme 
un modele Estelle en un modele intermediaire, annote de 
10 facon a assigner des temps d' executions non nuls aux 
transitions. Les temps peuvent avoir differentes 
distributions. Le simulateur/debogueur (Edb) , base sur 
le modele semantique d£fini dans la norme Estelle, 
comporte un jeu de fonctions speciales permettant des 
15 simulations interactives et aleatoires dans le cadre de 
1' Evaluation de performance. 

Configuration Planner [H. M. El-Sayed, D. 
Cameron and C M. Woodside, "A utomated performance 
modeling from scenarios and SDL design of distributed 
20 systems proceeding of International Symposium on 

Software Engineering for Parallel and Distributed 
Systems (PDSE'98), Kyoto, April 1998] est une approche 
^ visant, pour des systemes temps reel « temps mou » et « 
temps dur »,' a. transformer de maniere automatique un 
25 modele fonctionnel specifie en MSC en un modele de 
performance LQN (LayeredQueueing Network) . La 
simulation des modeles LQN permet d'optimiser, selon le 
critere du temps de reponse, la repartition et 
1 ' ordonnancement des taches sur 1' ensemble des 
30 ressources (les machines) du systeme. Dans ce modele la 
contrainte de m£moire est ignoree^ 
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SPEED (Software Performance Engineering Early- 
Design) [C. U. Smith and L. G. Williamns, "Performance 
Engineering Evaluation of Obj ectOriented Systems with 
SPE-ED" , Computer Performnance Evaluation Modelling 
Techniques and Tools, no. 1245, Springer-Verlag, 
Berlin, 1997] est un outil permettant d'evaluer 
1 ' architecture et des solutions alternatives pour la 
conception des systemes a objets. La specification 
fonctionnelle du systeme est sous forme des diagrammes 
de sequences representant des traces d' executions 
(scenarios). L' outil transforme le modele de 
specification en un modele de performance repr£sente 
par un systeme a files d'attente. Une combinaison 
d' analyse et de simulation permet d' identifier des 
15 problemes de performance potent iels, comme les 
phenomenes de goulot d' 6tranglement . 

TLC (Trace -Based Load Characterization) est une 
approche travaillant sur des traces d' executions du 
systeme, qui servent de base a la construction d'un 
2 0 modele de performance en couches (LQN, ou Layered 
Queuing Network) . Les traces - Message Sequence Charts 
- sont obtenues par simulation d'un modele SDL, mais 
doivent etre annotees afin d'expliciter les dependances 
causales qui existent entre les differentes actions 
25 r£alisees. Par une analyse des evenements detailles de 
la . simulation, les annotations des traces sont 
produites selon un principe de marquage incremental, 
qui s'apparente a la technique de coloration du sang 
utilisee en radiographic, 1 ' angiogramme . Une fois ces 
chainages causaux etablis, des schemas de 
communication, classiques dans les systemes logiciels, 
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sont identifies, en pratique, chaque message se voit 
attribuer un type, qui peut etre « RPC » (appel de 
procedure distante) , « Forward » (RPC propage a un 
tiers) , « Reply » (reponse a un RPC) , ou « Async » 
5 (emission asynchrone d'un message) . Sur la base de 
cette classification, un modele LQN est produit 
automatiquement, parametre puis analyse sur le plan des 
performances. Le module LQN est une specialisation du 
modele classique a files d'attente, adapte a la 
10 description d' architectures logicielles 

traditionnelles, telles que les systemes client - 
serveur . 

Inconvenient des techniques anterieures 

15 Les approches de l'art antSrieur citees ci- 

dessus consistent soit a effectuer des analyses 
directement sur un modele, soit a simuler un modele 
avec un simulateur specif ique . 

Dans le premier cas, les hypotheses de Markov 

20 sont omnipresentes . Elles peuvent eventuellement §tre 
verifies sur des systSmes simples. Cependant, elles ne 
s'appliquent gen^ralement plus dans le cas de systemes 
complexes a l'interieur desquels de nombreuses 
interactions ont lieu. Faire l'hypothese de Markov 

25 revient alors a considerer une approximation assez 
grossiere du systeme r§el , faute de mieux. Quant au 
second cas, la plupart des approches introduisent des 
annotations temporelles a l'interieur du modele 
fonctionnel. Le modele de performance qui en resulte 

30 comporte generalement beaucoup trop de details d'ordre 
fonctionnel, sans pertinence du point de vue des 
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performances, qui oberent l'efficacitg des programmes 
de simulation. II faut bien garder a 1' esprit qu'un 
modele fonctionnel et un modele de performance ont des 
object if s fondamentalement differents : du point de vue 
5 performance, on suppose que le systeme fonctionne 
correctement et par consequent, les details de 
f onctionnement (1' ensemble des proprietes logiques) 
n'importent pas, seules comptent la duree pendant 
laquelle une t&che detient le CPU et la politique 
10 d'ordonnancement qui gere les taches simultanSes . De 
meme, on ne considere pas les cas marginaux, qui se 
produisent rarement et dont I 1 influence sera 
negligeable statist iquement . Or, ces cas peuvent §tre 
nombreux et leur modele fonctionnel peut etre tres 

15 complexe . 

La derniere approche . TLC s^duit par le fait 
qu'elle considere un ensemble fini de scenarios, plutot 
qu'une description complete du systdme . Toutefois, le 
module de files d'attente en couches qui est vise (LQN) 

20 introduit des concepts de haut niveau qui, dans le but 
de favoriser la comprehension du systeme par I'humain, 
s'averent a la fois rigides et artificiels vis-a-vis de 
^ 1' analyse des performances, et restrict if s en termes 
. d' expressivite. 

25 Enfin, 1' approche TLC cherche a automatiser 

1' identification des liens de causality entre les 
differents ev^nements d'un scenario, ce qui nous semble 
tres delicat dans le cas general. En effet, la reaction 
d'un systeme a un stimulus, bien souvent, n' est pas 

3 0 conditionnee que par ce stimulus, mais egalement par 
l'gtat interne du processus ; or, 1' approche TLC 
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s' attache a cerner essentiellement les facteurs 
declenchants de type stimulus externe (messages) . En 
fait, la difficulty consiste a exprimer sur les 
scenarios toute 1 ' information de causalite necessaire a 
la simulation de performance, tout en parvenant a faire 
abstraction des details fonctionnels du systeme 3 . Comme 
nous le decrivons dans la suite, notre approche face a 
ce probleme est plus pragmatique, 1 ' identification des 
liens precis de causalite, trSs difficile pour une 
machine, se revele en general assez naturelle pour le 
concepteur humain. Aussi est-il preferable de mettre a 
contribution le savoir-faire et 1' intuition de ce 
dernier, dans la mesure oH il semble le plus apte a 
fournir le bon niveau d' information. 

Le but de 1' invention est de pallier les 
insuf f isances des systemes de l'art anterieur decrit 
ci-dessus au moyen d' un procede adapte aux plates- 
formes de services, dont le resultat principal est la 
production automat ique d'un modele de performance, a 
partir d'un modele fonctionnel du systSme etudie. Le 
modele de performance genere est dedie aux simulateurs 
logiciels du marche bases sur les systemes de files 
d'attente. Le modele fonctionnel s'exprime sous forme 
de diagrammes de sequences assortis de donnees 
25 temporelles. Les diagrammes de sequence peuvent etre 
derives d'une modelisation dynamique et complete du' 
systeme faite en SDL ou en UML. 



15 



20 



30 



Expose de 1' invention 

Le procede selon 1' invention comporte les 

etapes suivantes : 
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- Repartir les requStes representatives du 
systeme en un nombre fini de groupes et identifier, 
pour chaque groupe de requetes, le flot d' execution 
correspondant , la repartition desdites requetes etant 

5 determinee par le service invoque et par les 
caracteristiques du comportement propre du client, et 
le flot d' execution pour chaque groupe de requites 
correspond a 1 ' enchainement d' executions d' entites 
logicielles, en sequence et/ou en parallele, induit par 

0 une requite du groupe. 

Formaliser les flots d' executions a 
1'aide d'une notation permettant de mettre en evidence, 
d'une part, les relations causales entre les 
differentes entites logicielles du systeme impliquees 

5 dans les flots d' execution, et d' autre part, les 
informations caracterisant la consommation des 
ressources du systeme, telles que la duree d' occupation 
de CPU lorsqu'une entite logicielle est active. 

Elaborer un modele intermediaire 

0 comportant en plus des flots d' execution formalises, 
une specification de ressources decrivant les materiels 
physiques du systeme et une specification de 
.1' environnement representant le comportement des 
utilisateurs . 

5 - Automatiser la transformation du modele 

intermediaire elabore en un modele de performance. 

Preferentiellement, le modele de performance 
derive du modele intermediaire elabore est dedie aux 
simulateurs logiciels pre-existant utilisant des 

0 techniques de reseaux de files d'attente. 
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Selon vine caracteristique de 1' invention, la 
repartition des requites du systeme en un nombre fini 
de groupes de requetes est determinee par le service 
inyoqu# (sa nature) , et par les caracteristiques du 
5 comportement propre du client qui influencent la 
maniere dont se .r6alise le service invoque . Le flot 
d' execution pour chaque groupe de requetes est 
determine par l'enchainement d' executions d'entit6s 
logicielles, en sequence et/ou en parallSle, induit par 

10 une requete du groupe. 

Selon 1' invention, la topologie du moddle a 
files d'attente d^rivee de la transformation est 
entierement determinee par les flots d' execution 
correspondant aux groupes de requetes. 

15 Selon 1' invention, la derivation d' un modele de 

performance dedie & un simulateur pr6- exist ant bas6 sur 
des techniques des reseaux de files d'attente est 
automatisable par adaptation des regies de 
correspondance proposees . 

20 Selon uri mode de realisation, le formalisme des 

phases est realise a 1 7 aide d'une extension du 
formalisme MSC (Message Sequence Charts) , et la 
~ f ormalisation du graphe des phases et des flots 

d 7 execution d'un service a 1 7 aide du formalisme HMSC 

25 (High level Message Sequence Charts) est representee 
sous la forme d'un arbre comportant : 

- une plural ite de nceuds represent ant les 
phases const ituant le service ; 

- au moins un arc orient^ menant d'un nceud 
3 0 a un autre representant 1 ' enchalnement en sequence de 

deux phases ; 
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L'arbre de f ormalisation peut comporter en 

outre : 

- au moins un noeud suivi de plusieurs arcs 
orientes en parallele, 
5 - au moins un noeud suivi de plusieurs arcs 

orientes en f onction du choix de la phase suivante 
dependant soit d'une condition externe au systeme (liee 
par exemple a une caract£ristique du client) , soit 
d'une condition interne li6e a l'Stat courant du 
10 systeme. 

Ainsi, le modele intermSdiaire glabore 
comporte les flots d' execution formalises, associes a 
des donnees temporelles caracterisant le comportement 
d'entites logicielles et leurs interactions, au moins 

15 une specification des ressources dScrivant les 
mat^riels physiques, et au moins une specification 
d' environnement representant le comportement des 
utilisateurs . 

Un avantage par rapport au modele LQN reside 

20 dans la disponibilite sur le marchg de plusieurs 
ateliers de simulation industriels, a la maturity et a 
la puissance eprouvees . Des outils comme QNAP ou 
*** SES/Workbench proposent des f onctionnalitSs d' analyse 

avancees permettant de modeliser une tres grande 

25 vari<§te de systemes complexes, ainsi que la possibility 
de, configurer trds finement le modele, par exemple, les 
politiques d'ordonnancement des tSches peuvent etre 
red£finies de fa<?on algorithmique , si aucune ne s'avere 
suffisamment rgaliste parmi les politiques pr6d£finies. 
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Breve description des dessins 

D'autres caracteristiques et avantages de 
1' invention ressortiront de la description qui va 
5 suivre, prise a titre d'exemple non limitatif en 
reference aux figures annexees dans lesquelles : 

- la figure 1 illustre schematiquement le 
procede selon 1' invention ; 

- la figure 2 illustre schematiquement un 
10 modele intermediaire defini par le procede selon 

1' invention ; 

la figure 3 illustre schematiquement 
1' association des differents elements du modele 
intermediaire et des primitives du simulateur 
15 SES/Workbench base sur des systdmes a files d'attente ; 

les figures 4a a 4h illustrent 
schematiquement les regies de correspondance entre les 
evSnements annotSs caracterisant le comportement 
d'entites logicielles et des primitives du simulateur 
2 0 SES ; 

_ ia figure 5 illustre schematiquement un 
sous-modele SES derive d'un flot d' execution formalise 
^ en appliquant des regies de correspondance illustr^es 
dans les figures 4a a 4h ; 
25 - la figure 6 represente un sous-modele SES 

de 1 ' architecture globale du systeme obtenu en 
appliquant des regies de correspondance illustr€es dans 
la figure 3 ; 

la figure 7 illustre schematiquement 
30 I'arbre des phases repr^sentant les differentes etapes 
pour la realisation d'un service Audio - conference selon 
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le procede de 1' invention ; 

- les figures 8 a 10 reprSsentent les flots 
d' execution extraits de l'arbre des phases pour le 
service Audio- conference ; 

5 - les figures 11 a 20 repr§sentent des 

schemas de f ormalisations des phases du comportement du 

service fourni ; 

- La figure 21 represente la declaration 
des ressources, les flots d' executions et le sous- 

10 modele de 1 ' architecture globale d'une plate-forme 
d'audioconf erence dans le module SES ; 

- La figure 22 represente un sous -modele 
SES de 1' architecture globale de la plate-forme 
d' audio- conference ; 

15 - Les figures 23 a 25 reprgsentent les 

sous-modeles SES derives des differents 'flots 

d/ execution formalises en appliquant des regies de 
correspondance illustr£es dans les figures 4a a 4h. 

20 Expose detaille de modes de realisation particuliers 

Pour model is er un systdme 6tudi6, le proced§ 
selon 1' invention utilise les syst^mes & files 
d'attente. Ce choix est lie au fait que les simulateurs 
de performances les plus avances du march6 exploitent 
25 pour la plupart le moddle des r6seaux de files 
d'attente. Ces ateliers font preuve d'une maturity 
notoire, tant sur le plan de la richesse des 
fonctionnalit€s, que de la qualite de 1' analyse et de 
la robustesse. 

3 0 Rappelons qu'un modele d' un systeme & files 

d'attente se concentre sur les aspects qui ont un effet 



WO 03/092245 




PCT/FR03/01251 



direct ou indirect sur la consommation des ressources 
du systeme (processeurs et m^moires des machines, bande 
passante des reseaux de transport) . 

Le procede selon 1' invention permet de 
5 mod^liser essentiellement : 

• la repartition des entites logicielles 
dont la cooperation realise le service sur les 
diff^rentes machines; 

• les interactions, ou relations de 
10 causality, qui existent entre ces entites logicielles, 

• les durees de traitement unitaire, 

• les politiques d' ordonnancement des 
ttches concurrentes, 

• la capacite des reseaux sous-jacents 
15 (caract^risee par les d^lais de transmission et la 

politique de rout age) , 

• le comportement des utilisateurs 
caractSris6 par le. d£bit d'arrivee des requites, et par 
la distribution de la duree qui s6pare deux arrivees 

2 0 consecutive s • 

Un systeme logiciel rSparti se compose 
^ g§n<§ralement d'un ensemble d'entit€s. logicielles 
(processus, composant s , etc . ) s ' executant sur un 
ensemble de machines connect§es par des reseaux de 

25 transport. Ce type de systdme se mod^lise en associant 
un serveur muni d'une file d'attente a chaque couple 
compose d'une entity logicielle et d'une machine sur 
laquelle s' execute 1' entity. Deux entites logicielles 
heb^rgees sur une meme machine sont considerees comme 

30 deux serveurs distincts. Pour chaque serveur ainsi 
d§fini, son service et sa file d'attente correspondent 
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respect ivement a 1' execution de l'entite et & la 
memoire de la machine. 

Les clients sont les requites envoyees par les 
utilisateurs invoquant des services fournis par le 
5 systeme. Quant a la topologie du systeme a files 
d'attente, elle est determinee entierement par les 
traces d' execution. En effet l'arrivee d'une requete 
dans le systeme provoque l'ex6cution d' actions sur les 
serveurs. Ces actions peuvent evoluer simultanement (en 

10 parallele) ou se synchroniser en sequence. Chaque trace 
d' execution est ainsi representee par une arborescence 
de serveurs. En definitive, la topologie globale du 
reseau de files d'attente est telle que toutes les 
traces d' execution sont couvertes . 

15 Avant de proceder a la simulation du modele, 

celui-ci doit encore etre complete d'un modele 
d' environnement et d'un modele de ressources. Le 
premier caracterise le comportement des utilisateurs, 
en termes de debit et de distribution statistique des 

20 temps d' inter-arrivees. Le second precise la duree 
d' execution de chaque entite lorsque la machine lui est 
entierement dediee (tests unitaires) , les delais de 
«^ transmission caracterisant la capacite des reseaux et 
la politique d' ordonnancement des traitements 

25 concurrents. Ces donnees peuvent etre integrees dans le 
modele fonctionnel du systeme. La simulation consiste a 
injecter un tres grand nombre de requetes dans le 
modele. On optimise l'utilisation des ressources du 
systdme en cherchant une bonne configuration (ou 

30 parametrage) des differents elements du modele. La 
qualite de la configuration globale s'evalue en 
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etudiant par simulation son impact sur la charge des 
serveurs, sur le taux d' occupation des tampons, et sur 
des quantites caracterisant la qualite de service: les 
temps de reponse d'un composant particulier ou du 
5 systeme (de bout en bout) , la capacite de trait ement 
maximum (volumetrie) , etc. 

Pour des logiciels repartis quelconques, 
1 ' identification des interactions ou relations de 
causalite entre les entites logicielles peut etre tr£s 

10 complexe, voire impossible. En fait, la demarche 
proposee par 1' invention est applicable aux systemes 
dont on peut raisonnablement resumer le comportement 
par un ensemble restreint de scenarios d' execution. 
Id<§alement, les scenarios choisis evolueront 

15 i ndependamment les uns des autres . Neanmoins, les 
systemes impliquant des dependances entre scenarios 
sont acceptables (en cas d' interaction entre deux 
clients par exemple) , tant que ces dependances 
demeurent clairement exprimables par le concepteur. 

20 Les plates -formes de services constituent en ce 

sens un champ d' application concret pour la mise en 
oeuvre de 1' invention. En effet, 1 ' utilisation de ce 
type de plate- forme peut souvent St re caract6ris6e par 
un nombre raisonnable de scenarios, qui correspondent 

25 aux diff brents cas d' utilisation de la plate-forme 
(autrement dit, au traitement des diff ^rentes requStes 
emises par les utilisateurs lors de 1' invocation des 
services) , et qui dependent faiblement les -uns des 
autres . 

30 Comme cela est illustre schematiquement par la 

figure 1/ le veritable point de depart, pour la 
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generation d'un module de performance a files 
d'attente, consiste a repartir les requetes 
representatives du systeme en un nombre fini de groupes 
de requetes. et a identifier (etape 2), pour chaque 
5 groupe de requetes, le flot d' execution correspondant . 
Ceci permet de determiner la topologie globale du 
systeme a files d'attente afin que s'y re fie tent toutes 
les traces d' execution induites par des requetes 
representatives. Les requetes representatives sont 

10 celles dont la frequence d' emission dans le systeme est 
significative. La repartition de ces requites est 
determinee d'une part par le service invoque ; et 
d' autre part, par les caracteristiques du comportement 
propre du client qui influencent la manidre dont se 

15 realise le service invoque (voir dans l'exemple 
d'Audioconference) . Quant au flot d' execution pour 
chaque groupe de requetes, il correspond a 
1 ' enchainement d' executions d'entites logicielles, en 
sequence et/ou en parallele, induit par une requete du 

20 groupe. 

Repartition des requetes et identification des flots 
d' execution : 

Pour la premiere etape (n°2 sur la figure 1) , 
chaque service du systeme est represents sous la forme 
d'un arbre aux caracteristiques suivantes : 

- les noeuds de 1' arbre representent les 
phases constituant le service. Un noeud particulier, le 
noeud initial, correspond a la phase qui initie le 
service ; 

- un arc oriente menant d'un nceud a un 



25 
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autre represente 1' enchainement en sequence de deux 
phases 

- lorsque plusieurs arcs sont issus d'un 
m§me nceud N, cela correspond soit a 1' execution en 
5 parallele de toutes les phases suivantes, *soit & un 
choix de 1' execution d'une et une seule des phases 
suivantes. Dans ce dernier cas, le choix de la phase 
suivante est lie k une condition portant soit sur une 
propriety lige au comportement de 1 ' utilisateur , la 
10 condition est alors dite externe, soit sur l'etat 
courant du syst£me, dans ce cas, la condition est dite 
interne . 

Les requetes sont nature llement regroup^es sur 
la base des choix effectues au niveau des conditions 

15 externes. Les flots d' execution correspondants peuvent 
etre extraits de l'arbre global en parcourant celui-ci 
a partir du noeud initial, et en ne retenant qu'un seul 
successeur a chaque condition externe rencontree . Par 
consequent, un flot d' execution est un sous-arbre de 

20 l'arbre global caracterise par la transformation 
systematique de tout alternative externe parmi N 
successeurs en un enchainement en sequence vers un seul 
oor 3 e ces successeurs. Lors du parcours, tout autre aspect 

structurel de l'arbre est en revanche conserve 

25 (enchainement en sequence vers un noeud simple, 
enchainement parallelise vers plusieurs noeuds en 
simultan6, enchainement conditionn6 par l'etat interne 
du syst^me) . Les figures 8 a 10 illustrent les flots 
d' execution extraits de l'arbre des phases (figure 7) 

30 dans l'exemple du service Audio-conference. 
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Pormalisation des flots d' execution 

L'etape 4 du procede (figure 1) consiste a 
formaliser les flots d' execution a. l'aide d'une 
notation permettant de mettre en evidence les 
interactions entre les differentes entites logicielles 
impliguees dans les flots d' execution et les 
informations caracterisant la consommation des 
ressources du systeme. 

Dans le mode de realisation decrit, cette 
formalisation est basee sur les Message Sequence Charts 
(MSC) . Cependant, d'autres formalismes de diagrammes de 
sequence pourraient etre utilises. La coherence d'un 
MSC est optimale si le diagramme est produit en tant 
15 que trace d' execution du systeme. En phase de 
conception, une specification executable, du systeme 
peut-Stre produite en langage SDL, qui se trouve §tre 
un formalisme etroitement lie aux MSC sur le plan de la 
semantique. En pratique, tous les outils SDL sont 
20 capables de produire des traces de simulation dans le 
format MSC. Ces mSmes outils off rent en outre la 
possibility d' editer manuellement de tels diagrammes, 
et c'est ainsi que l'on pourra proceder a defaut 
d' exploiter la simulation d'un modele SDL. 
25 Les evenements qui apparaissent sur un 

diagramme MSC portent essentiellement sur des aspects 
fonctionnels : emission ou reception de message, 
action, armement ou expiration de temporisation, etc. 
En realite, ce niveau d' information est non pertinent 
ou insuffisant pour un modele de performance : par 
exemple, le nom des messages n'a pas d' importance . Pour 
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rendre possible la production d'un modele de 
performance, il est necessaire de preciser, pour les 

evenements concernes : 

la duree d' occupation du processeur 

5 engendree par le traitement de l'evenement. 

les conditions d' enchainement , qui 
specif ient dans quelle mesure 1' execution d'un flot 
peut se poursuivre. Une condition d' enchainement porte 
soit sur l'attente de 1' expiration d'un delai, soit sur 

10 la validite d'une expression booleenne. Elle peut etre 
vue comme une porte faisant obstacle a la pour suite de 
1' execution, et les composantes de la condition comme 
les cles qui doivent etre rassemblees pour franchir 
cette porte. Ces cles doivent etre definies par le 

15 concepteur et servent a indiquer la realisation de 
certains faits qui contribuent alors a la validation de 
la condition d' enchainement . Ces cles seront 
typiquement representees par des indicateurs booleens 

tels <Z* & par 

20 exempleutilisateur_connecte . nb_max_tentatives_atteint , 

etc . 

- la publication de faits, qui peuvent 
avoir un effet declencheur sur le deblocage d'autres 
flots. Le traitement d'un evenement peut contribuer a 
25 remplir les conditions d' enchainement qui bloquent 
1' execution d'une autre entite. Dans l'analogie avec 
les cles, cela correspondrait a l'acte de fournir 
certaines cles aux autres entites du systeme, de 

« piablier des faits ». 

la terminaison eventuelle d'une des 

branches paralleles dans un flot d' execution. 
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Ces quatre types d' information sont 
indispensables au modele de performance, pour calculer 
le temps de reponse, la repartition de charge des 
machines, la longueur des tampons, etc. Le procede 
5 definit cinq clauses correspondantes (dont deux pour 
les conditions d' enchainement) , qui constituent ainsi 
1' extension de la notation pour formaliser les flots 
d' execution : EXEC (occupation du processeur) , EXPECT 
(condition d' enchainement sur une expression 

10 booleenne), DELAY (condition d' enchainement sur 
l'ecoulement du temps), PUBLISH (publication de faits) , 
et END (terminaison de la branche du flot) . Les figures 
11 a 20 illustrent les flots d' execution formalises 
dans l'exemple d'un modele fonctionnel du service 

15 Audioconf erence . 

Elaboration du modele intermediaire 

L'etape 6 du procede (figure 1) cons is te a 
def inir un modele intermediaire destine a permettre le 

20 passage automatique a un modele de performance. Sur la 
figure 2, on voit que ce modele est compose des flots 
d' execution formalises (10) caracterisant le 
comportement d'entites logicielles et leurs 
interactions, d'une specification des ressources (12) 

25 decrivant les materiels physiques, et d'une 
specification d' environnement 14 representant le 
comportement des utilisateurs . 

Le modele de ressources contient les 
declarations suivantes : 

30 - les machines, la taille des tampons et la 

politique d' ordonnancement des traitements simultanes 
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de ces machines ; 

les reseaux de transport et leurs 
topologies permettant la connexion des machines ; 

- les entites logicielles (programmes a 
unique fil d' execution) , ainsi que leur repartition sur 
les ressources ; 

- les capacit^s des machines exprimees par 
rapport aux temps de traitement unitaires des ttches 
( formal i sees par EXEC) ; 

- les capacites des liens de transmission 
exprimees par rapport aux delais de transmission ; 

Dans le module d' environnement , qui caract£rise 
le trafic de requetes genere par les utilisateurs, il 
15 faut preciser les donnees suivantes : 

- le debit d'arrivee des requites ; 

- le rythme d'arrivee ; il est caracterise 
entierement par la distribution de la duree separant 
deux arrivees cons^cutives ; 

20 - les attributs ; ce sont des variables 

propres a chaque requ§te ; ils permettent notamment 
d' identifier les dif f erentes classes de requetes 
determinees par les flots d' execution ; d'autres 
variables servent a exprimer les conditions booleennes 
25 de synchronisation entre des branches paralleles d'un 
meme flot d' execution. 

la proportion de chaque classe de 
requetes (cette repartition est fournie par des 
observations ou des estimations quant a 1' usage futur 
3 0 de la plate- forme) 
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Transformation automatique en un modele de 
performance!.' 6tape 8 du procede (figure 1) consiste a 
definir des regies de correspondance entre les elements 
du modele intermediaire ' et les primitives d'un 
simulateur generaliste base sur des systemes a files 
d'attente. La transformation devient automatique 
lorsqu'on applique ces regies de correspondance. Ces 
dernieres s'appliquent aussi bien a tous les 
simulateurs de cette categorie : tous sont fondes sur 
les memes concepts de base, seul le mode de 
representation de ces concepts differe. La coherence de 
la transformation repose sur des regies de semantique 
(non explicitees dans le present document) , qui 
permettent de detecter les sp6cif ications erronees 
conduisant a des modeles de performance incomplets ou 
denues de sens. Nous illustrons ici la demarche dans le 
cas d' utilisation du simulateur SES /Workbench. 

La figure 3 illustre schematiquement les regies 
de correspondance entre le modele intermediaire et des 
D « nceuds » SES/Workbench. En designant respectivement 
par R={machine_l, machine_m} et 

F={flotExecFormalise_l, f lotExecFormalis6_n} 

1' ensemble des machines du systeme declarees dans le 
modele de ressources et 1' ensemble des flots 
5 d' execution formalisms des services du systeme : 

- Le modele d' environnement 14 est associe 
a un noeud « source » 20, suivi event uellement d'un noeud 
« submodel » 22. Ce dernier est utile dans les. cas plus 
complexes, par exemple dans le cas de requeues 

0 structurees par sessions ou a plusieurs niveaux ; 

- Le modele de ressources 12 contenant la 
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declaration de 1 ' ensemble R de m machines est associ6 a 
un ensemble de m noeuds « service » denotes par un nom 
logique (serveurj par exemple) , pour tout j ; 

- Chaque f lotExecFormalise_i 10 est associe' 
5 a un noeud « submodel » denote par un nom logique 

(flotExec_i par exemple) pour tout i ; 

- Chaque noeud « submodel » associe au flot 
d' execution formalist est dSveloppe, en faisant les 
correspondances suivantes entre evenements du flot 

10 d' execution formalist et primitives SES. Les 
diffSrentes associations sont decrites par les figures 
4a & 4h. 

En reference a la figure 4a, la primitive 
« EXEC(t) » est associSe a une sequence de deux noeuds : 
15 un noeud « user », suivi d'un noeud « service 
reference_to ». Le noeud user permet de specifier la 
valeur de t correspondant a la. duree d' execution de 
code, tandis que le noeud « service reference_to » fait 
reference au noeud service declare dans le module qui 
20 correspond a la machine hgbergeant le processus qui 
effectue le « EXEC(t) ». 

La publication de faits « PUBLISH » est 
associ^e (figure 4b) a un noeud « user » contenant le 
programme C adequat . Ce programme modifie les variables 
25 qui representent les cles ou faits i. publier. 

La fin de branche de flot « END » est associSe- 
a un noeud « sink » (figure 4c) . 

La primitive « DELAY (t) » est associee a un 
noeud « delay » (figure 4d) et la valeur de t est le 
3 0 parametre du noeud. 
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La condition d' enchainement « EXPECT » est 
associee a un noeud « block ou elle s'exprime par une 
expression booleenne c donnee en parametre du noeud 
(figure 4 e) . 

5 L' enchainement en sequence des evenements est 

represents par un arc entre les nceuds (figure 4f ) . 
Le choix d'un enchainement des evenements parmi N 
enchainements possibles est reprSsente par N arcs 
partant du noeud ou le choix a lieu. Les conditions 
10 determinant un choix sont spScifiSes dans 1'arc 
correspondant (figure 4g) . 

Enfin la separation du flot en N branches 
paralleles est representee par un noeud « split » 
(figure 4h) . 

15 La figure 5 illustre la sequence correspondant 

au sous-modele d'un flot d # execution formalise 
complStee par un noeud « enter » et par un noeud 
« return » qui representent respect ivement 1' entree et 
la sortie du sous-moddle. 

20 La figure 6 illustre 1 ' architecture globale du 

systeme, qui rassemble les sous-modeles flots 
d' execution et le sous-modele d ' envi ronnement . 

Exemple d' application : plate-forme d # Audio -conference 

25 Presentation informelle du service d' audio- 

conference . 

Le service d ' Audio- conference permet £ un 
nombre determine d'usagers, sur accord prealable, 
chacun de son cote et a une date et heure convenues, de 
30 composer un numero d' appel afin d'etablir une 
communication vers un pont de conference. La 



WO 03/092245 



37 



PCT/FR03/01251 



reservation d'un pont de conference .ayant prealablement . 
gte effectuee par l'un des participants, qui a precise 
la date, l'heure, la duree et le nombre de 
participants . 

5 La realisation du service d' etablissement d'une 

session de conference, offert par la plate- forme 
d' Audio- conference, depend du role (de la nature) du 
client qui l'invoque : 

- est-il organisateur de la session ? 
10 - est-il un simple participant ? 

- est-il autorise a participer a la session ? Cette 
classification permet d' identifier les differents types 
de requStes. Par ailleurs, il se peut qu'un type de 
requete interagisse avec un autre. Par exemple, le 

15 traitement de la requete d'un simple participant a une 
session d' Audio- conference est suspendu jusqu'a 
l'arrivee de 1 ' organisateur de cette session. 

Un r61e particulier est affecte a 
1' Organisateur de la conference. La' conference ne peut 

20 commencer avant l'arrivee de 1 ' Organisateur , c'est-a- 
dire que les participants ne peuvent pas etre connectes 
au pont de conference tant que 1 ' Organisateur est 
=w absent. La conference est fermee apres raccrochage de 
1' Organisateur, et les participants encore en . ligne 

25 seront alors deconnectes du pont de conference. La 
souscription, qui consiste principalement en la 
reservation d'un numero d' acces au pont de conference, 
s'opere par 1' intermediaire du fournisseur de service. 
Les donnees sont en consequence recuperees dans la base 

30 de donnees . 
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Traitement d' appel 

Le traitement d' appel se decompose suivant les 
phases suivantes (remarque : on ne s'interesse, pour 
cette etude de cas, qu'a l'ouverture de conference^/ et 
5 non a leur Evolution ni & leur cloture) : 

1) Un participant compose le numgro d'acces a la 
conference programm€e (numero d'accSs au service NAS) . 
Ce numero est compost d'un prefixe de type OZABPQ 
specif ique au service, tandis que le suffixe MCDU est 

10 specif ique a la conference souscrite. Le service 
effectue la traduction du numero d'accds au service en 
numero reel d'acces au pont de conference (NAC) . 

2) Plusieurs cas sont possibles: 

- Tant que le nombre de participants est inf£rieur k la 
15 capacite maximale du pont de conference et que 

1' Organisateur n'a pas invoque le service, un message ■ 
est emis qui annonce le retard de 1 1 organisateur , puis 
un second invitant k attendre l'ouverture de la 
conference. 

20 Quand 1 ' Organisateur se presente, les 

participants en attente sont alors connects au pont de 
conference (ainsi que 1' Organisateur) . La conference 
^ est dite ouverte. 

- Si le nombre de participants d£ja connectes atteint 
25 le nombre maximal defini par le souscripteur , le 

service rejette 1' appel avec un message de saturation. 

Messages specifiques au service 

Les libelies des messages specifiques au 
30 service sont les suivant s : 

- accueil : "vous avez compost un numero d'acces a une 
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conference, veuillez ne pas quitter". 

- saturation : "le numero compose est sature, nous ne 
pouvons donner suite a votre appel" . 

- incident : "suite a un incident,, nous ne pouvons 
donner suite a votre appel". 

- annonce : "votre organisateur n'est pas encore 
connect 6..." . 

- attente : "veuillez ne pas quitter, vous serez mis en 
communication avec vos correspondants des ouverture de 
la conference..." . 

Donnees 

Les donnees specifiques au service sont : 

- les n° d'acces au service 

- les n° traduits (le numero reseau du pont) 

- le nombre maximal de participants par pont de 
conference 

- l'etat de la ressource associee au pont de conference 

- la table des annonces 

) - les tables d' analyse nationale, internationale et 
speciale (pour des contr61es eventuels sur le numero 
appelant) . 

Ces donnees sont de differents types, suivant 
que leur modification se fait ou non par les scripts du 

5 traitement d' appel-. Les donnees non modifiables par le 
traitement d' appel sont dans une base de donnees 
appelee ici SDF (Service Data Function) , elles sont 
accessibles en lecture par les scripts du traitement 
d' appel et en ecriture pas des scripts de gestion. Les 

0 donnees modifiables par le traitement d' appel sont dans 
une base de donnees accessible en lecture et ecriture 
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par les scripts du traitement d'appel, cette base de 
donnees doit foumir des performances d'acces plus 
importantes . Ce dernier type de donnee est. represents 
ici par le nombre maximal de participants, et par 
5 l'etat de la ressource. 

Application des etapes du procede 

A partir de la description informelle du 
service, la premiere etape consiste a identifier les 
0 phases elementaires et leur organisation en un arbre de 
phases . 

Tous les comportements des utilisateurs ne sont 
pas pris en compte, seuls sont exprimes les cas 
d' utilisation les plus representatif s . En particulier, 
.5 les raccrochages sont pris en compte en phase de 
conversation et en phase d'attente, cas de raccrochage 
les plus pertinents d'un point de vue utilisateur. 

La figure 7 illustre 1' arbre global des phases 
qui decrit 1 ' enchainement des differentes phases en 
0 precisant les alternatives internes ou extemes . On 
reconnalt les conditions extemes au fait que les arcs 
qui en sont issus portent des pourcentages 

statistiques. 

Apres une phase de connexion PI, une 

25 alternative externe permet d' identifier si 
1' utilisateur est 1 ' organisateur (P2) ou un simple 
participant (P4) . Si 1'utilisateur est un participant, 
une alternative interne {nbParticipants<MAXl} , dont 
1' option depend de 1' execution d' autres scSnarios, 

3 0 identifie si le nombre maximum de participant est 
atteint ou non. Si ce nombre est atteint, une phase 
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pour 1' envoi d'un message de saturation est initiee 
(P6) . Si ce nombre maximum n'est pas atteint (P5) , une 
deuxieme alternative interne {organisateurPresent} 
permet d' identifier si 1' organisateur est deja present. 
5 S'il est deja present, le participant est connect! au 
pont (P7, avec en pr£alable un message d'accueil) . Si 
1' organisateur est absent, un message d' attente est 
emis vers le participant (phase P8) . De cette phase, 
une condition externe {participantPatient } permet de 
10 distinguer le cas ou le participant attend l'arrivee de 
1' organisateur (phase P10) et entre dans la conference 
(phase P7) a l'arrivee de 1' Organisateur, du cas ou le 
participant est plut6t du type " impatient », c'est-a- 
dire qu'il raccroche suite a 1 1 annonce de retard 
15 dif fusee en phase P9 . Dans ce cas, le nombre de 
participants est diminue d'une unite. Encore une fois, 
on suppose que seules les performances des phases liees 
a 1 ' etablissement de la conference nous interessent 
dans cet exemple, ce qui explique que 1 • arbre ne 
20 contienne aucune phase liee a 1' evolution ulterieur de 
la conference . 

Les requetes dans 1' exemple sont reparties en 
trois groupes : requ§tes envoyees par un organisateur ; 
requites envoyees par un simple participant patient ; 
25 et requetes envoyees par un simple participant 
impatient. A partir de 1' arbre global des phases, on 
extrait alors les trois flots d' execution 
correspondants en ne gardant qu'une branche de chaque 
alternative externe : 
3 0 - fiot d' execution induit par l'arrivee de 

1' organisateur (figure 8) ; 
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- flot d' execution induit par l'arrivee 
d'un simple participant patient (figure 9) ; 

- flot d' execution induit par l'arrivee 
d'un simple participant impatient (figure 10) . 

5 

Identification des cles et portes des phases concernees 

La deuxieme etape du procede consiste a 
identifier les cles et portes qui influencent le 
comportement d'un cas d' utilisation a partir du 
10 comportement d'un ou plusieurs autres cas 
d' utilisation. Dans le cas du service d' Audio- 
conference, on identifie une ' cle liee a la presence de 
l'organisateur. La phase P3 , executee lors de l'arrivee 
de l'organisateur, inclut la 

15 tache PUBLISH (organisateurPresent) . 

Une telle publication permettra de debloquer la 
phase PIO qui inclut une tache 

« EXPECT (organisateurPresent) ». 

La variable nbParticipants est augmentee de 1 
20 lors de la connexion d'un utilisateur (non 
organisateur) , sauf si elle vaut deja sa valeur maximum 
autoris6e (MAXI) . Ce test est represents par une 
v alternative interne dans 1 ' arbre de phases. 

25 Pormalisation des phases 

Les figures 11 a 20 representent des schemas de 
formalisation des phases du comportement du service, 
les MSC associes a differentes phases du comportement 
du service seront donnes avec une vue simplifiee sur le 
3 0 nom des signaux. De meme, tous les echanges ne sont pas 
indiques afin de ne pas alourdir les schemas. 
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Les instances considSrees dans ces MSC sont : 

- le SDF (Service Data Function ou base des donnees de 
service) , 

- le SCF (Service Control Function ou plate-forme 
d' executions des services), 

- le SRF (Service Resource Function ou plate-forme 
vocale) et les USER (utilisateurs) . 

Les echanges de signaux correspondent: 
aux interrogations de la base de donnSes : 

• appelant (numeroAppelant) interroge la base 
sur le numero appelant (P2,P4) ; 

• typeAppelant est la reponse de la base, 
elle peut prendre les valeurs ORGAN I S ATEUR 
(si 1' appelant est 1 ' organisateur) ou 

15 PARTICIPANT (si 1' appelant n'est pas 

1' organisateur) . 
aux echanges de messages vocaux en passant par la 
plate- forme vocale : send_message vers la plate- forme 
vocale, msg_info vers 1' utilisateur (P6, P7, P9) . 
2 0 - aux ^changes pour la synchronisation par les 
portes : 

• PUBLISH (organisateurPresent) permettra de 
publier le fait que 1 ' organisateur vient 
de se connecter . 
25 • EXPECT (organisateurPresent) permet le 

blocage de l 1 execution de 1 1 entite SCF 
jusqu'a l'arrivee de 1' organisateur . 
La figure 11 represente la f ormalisation de la 
phase d' invocation du service. 

La figure 12 represente la f ormalisation de la 
phase « Identif icationOrganisateur ». 
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La figure 13 represente la f ormalisation de la 
phase « Identif icationParticipant. » . 

La figure 14 represente la f ormalisation de la 
phase « OuvertureDeLaConference » • 
5 La figure 15 represente la f ormalisation de la 

phase « ConnexionParticipant » . 

La figure 16 represente la f ormalisation de la 
phase « DeconnexionSuiteASaturation » . 

La figure 17 represente la f ormalisation de la 
10 phase » EntreeDansLaConf erence » . 

La figure 18 represente la f ormalisation de la 
phase « AnnonceRetardOrganisateur » . 

La figure 19 represente la f ormalisation de la 
phase « AttenteOrganisateur » . 

La figure 2 0 represente la f ormalisation de la 
phase « AbandonSurAttente » . 



15 



20 



Modele de performance derive du modele f onctionnel 

La figure 21 represente la vue generale du 
modele intermediate (dans SES/ Workbench) . On y 
trouve : la declaration des ressources, les trois flots 
d' executions et le sous -module de 1 ' architecture 
globale de la plate-forme d' Audio- conference. Dans cet 
exemple, les processus SDF, SCF et SRF g'executent 
25 chacun sur une machine. 

Une vue interne de 1' architecture globale de la 
plate-forme est representee par la figure 22. 

Le nceud initSession initie la creation du 
nombre maximum de sessions simultanees autorisees par 
la plate-forme. Le ncsud appelsDuneSession genere les 
appels pour chaque session ouverte et le nceud 
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interAppOrdre model ise les durees qui separent les 
appels consecutifs d'une session et le rang auquel 
arrive 1 ' organisateur . Enfin, chaque fin de session, 
representee par le noeud f ermetureSession declenche la 
creation d'une nouvelle session representee par le noeud 
creationSession . 

Les Figures 23, 24, et 25 montrent 
respectivement les trois sous-modeles resultant de la 
transformation des flots d' executions de 

1' organisateur, d'un participant patient, et d'un 
participant impatient. 
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RE VEND I CAT IONS 

1. Procede de generation d' un modele de 
performance a partir d'un modele fonctionnel d'un 
systeme comportant une plurality d'entites materielles 
et logicielles reparties cooperant pour fournir un 
service a au moins un utilisateur, caracterise en ce 
qu'il comporte les etapes suivantes : 

- Repartir les requStes representatives du 
systeme en un nombre fini de groupes et identifier, 
pour chaque groupe de requetes, le flot d' execution 
correspondant, la repartition desdites requetes etant 
determinee par le service invoque et par les 
caracteristiques du comportement propre du client, et 
le flot d' execution pour chaque groupe de requetes 

15 correspond a 1 ' enchainement d' executions d'entites 
logicielles, en sequence et/ou en parallele, induit par 

une requite du groupe, 

- Formaliser les flots d' execution 'a l'aide 
d'une notation permettant de mettre en evidence, d'une 

20 part, les relations causales entre les differentes 
entites logicielles du systeme impliquees dans les 
flots d' execution, et d' autre part, les informations 
■» caracterisant la consommation des ressources du 
systeme, telles que la duree d' occupation de CPU 
25 lorsqu'une entite logicielle est active. 

Elaborer un modele intermediaire 
comportant en plus des flots d' execution formalises, 
une specification de ressources decrivant les materiels 
physiques du systeme et une specification de 
l'environnement representant le comportement des 
utilisateurs. 



30 



WO 03/092245 



47 



PCT/FR03/01251 



10 



- Automatiser la transformation du modele 
intermediate elabore en un modele de performance. 

2. Procede selon la revendication 1, caracterise 
en ce que le modele de performance derive du modele 
intermediate elabore est dedie aux simulateurs 
logiciels pre-existant utilisant des - techniques de 
reseaux de files d'attente. 

3. Procede selon la revendication 1, caracterise 
en ce que la repartition des requetes du systeme en un 
nqmbre fini de groupes de requetes est determinee par 
le. service invoque et par les caracteristiques du 
comportement propre du client qui influencent la 
maniere dont se realise le service invoque. 

4. Procede selon l'une des revendications 1 a 3, 
15 caracterise en ce que le flot d' execution pour chaque 

groupe de requetes est determine par 1 ' enchainement 
d' executions d' entites logicielles, en sequence et/ou 
en parallele, induit par une requete du groupe. 

5. Procede selon la revendication 4, caracterise 
20 en ce que la topologie du modele a files d'attente 

derive de la transformation est entierement determinee 
par les flots d' ex6cution correspondant aux groupes de 
requetes . 

6. Procede selon la revendication 4, caracteris6 
25 en ce que la derivation d'un modele de performance 

dedie a un simulateur pre-existant base sur des 
techniques des reseaux de files d'attente est 
automatisable par adaptation des regies de 
correspondance proposees . 

7. Procede selon l'une des revendications 1 a 6, 
caracterise en ce que le formalisme des phases est 
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realise a 1'aide d'une extension du formalisme MSC 
(Message Sequence Charts) . 

8. ProcedS selon 1'une des revendi cat ions 1 a 
7, caractSrise en ce que la f ormalisatibn du graphe des 

5 phases et des flots d' execution d'un service a I'aide 
du formalisme HMSC (High level Message Sequence Charts) 
est represent^ sous la forme d'un arbre comportant : 

- une pluralite de noeuds representant les 
phases constituant le service ; 
10 - au moins un arc oriente menant d'un noeud 

a un autre representant 1 ' enchai nement en sequence de 

deux phases ; 

9. ProcSde selon la revendication 8, 
csiractSrise en ce que 1' arbre de f ormalisation comporte 

15 en outre : 

- au moins un noeud suivi de plusieurs 
arcs orientes en parallele, 

- au moins un noeud suivi de plusieurs 
arcs orientes en fonction du* choix.de la phase suivante 

20 dependant soit d'une condition externe au systeme, soit 
d'une condition interne li6e a 1'etat courant du 
systdme . 

& io. ProcSde selon l'une des revendi cat ions 1 a 

9, caracterisS en ce que le modele intermSdiaire 

25 elaborS comporte les flots d' execution formalisms 
caractgrisant le comportement d'entitSs logicielles et 
leurs interactions, au moins une specification des 
ressources decrivant les materiels physiques, et au 
moins une specification d'environnement representant le 

30 comportement des utilisateurs . 
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